查看原文
其他

系统稳定性建设实践总结

架构精进之路 架构精进之路 2022-09-05


2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。

开篇

在开始介绍服务稳定性之前,我们先聊一下SLA。SLA(service-level agreement,即 服务级别协议)也称服务等级协议,经常被用来衡量服务稳定性指标。通常被称作“几个9”,9越多代表服务全年可用时间越长服务也就越可靠,即停机时间越短。通常作为服务提供商与受服务用户之间具体达成承诺的服务指标——质量、可用性,责任。

3个9,即99.9%,全年可停服务时间:365 * 24 * 60 *(1-99.9%)= 525.6min

4个9,即99.99%,全年可停服务时间:365 * 24 * 60 *(1-99.99%)= 52.56min

5个9,即99.999%,全年可停服务时间:365 * 24 * 60 *(1-99.999%)= 5.256min

在严苛的服务级别协议背后,其实是一些列规范要求来进行保障。

一、系统稳定性建设是指什么?

关于系统稳定性是指什么这一问题,相信好多开发同学都会有自己的理解和认知,但可能会存在是否理解片面或者是否标准的疑惑,那到底有什么判定标准和划分边界呢?

我们不妨看下来自于维基百科的解释:

稳定性是数学或工程上的用语,判别一系统在有界的输入是否也产生有界的输出。

若是,称系统为稳定;若否,则称系统为不稳定。

简单理解,系统稳定性本质上是系统的确定性应答

从另一个角度解释,服务稳定性建设就是如何保障系统能够满足SLA所要求的服务等级协议。

二、为什么需要系统稳定性建设?

可以确定的一点,服务稳定性建设是非常必要的,不管是满足日常系统正常运行还是重大节庆活动的稳定有序运营。

我们来看几个由于服务稳定性故障造成影响的案例:

1)2020年国庆前一天,受“2020年最难打车日”的需求影响,滴滴平台和嘀嗒平台相继出现宕机故障;

2)2018年亚马逊prime day:亚马逊会员日故障(顾客无法将商品添加到购物车结账),导致公司损失高达9900万美元。

3)2015年由于中国工商银行部分地区因计算机系统升级,造成柜面和电子渠道业务办理缓慢,甚至不能受理业务;

4)2012年12306铁路订票网站因机房空调系统故障,导致暂停互联网售票、退票、改签业务。

服务稳定性对于企业来说非常重要,不仅仅会对企业带来直接的经济损失,甚至会对行业、人们的生活造成非常严重的影响。所以说服务稳定性建设的意义非常重大。

三、系统稳定性建设为什么难?

关于稳定性以及如何提升稳定性指标,我们可以想到很多的优化项:

eg. 加服务器、扩容、超时重试、服务降级、资源隔离&备份、代码逻辑优化、异步事件化...

那系统稳定性建设的主要难点是什么呢?

3.1 面对的挑战比较大

  • 流量未知

尤其对于一个新改革上线的新业务而言,系统稳定性建设主要是流量洪峰的是个未知数,由于没有经验可以参考,我不确定是百万级别还是千万级别,还是更高级别?

  • 改动量大

往往这种系统稳定性建设需要考虑需求主要是短时间内支持XX能力的上线,这其中往往涉及系统层面从下到上的多处变更,包括底层数据结构调整、业务逻辑改造以及用户交互方式的优化等等。时间短,改动大,质量难以保证。

  • 不确定性

软件工程往往被用来描述“研究用工程化方法构建和维护有效的、实用的和高质量的软件”。其包括软件建设的方方面面,凡事事无巨细,任何细微的疏忽都可能造成全盘故障问题,不确定性问题尤其严重。

3.2 系统稳定性建设是一个系统性的大工程

多环节分工精细复杂,不容一点疏忽。

从系统构成来看,可以区分为单服务系统稳定性和多服务集群稳定性。

  • 单服务稳定性

主要包括:功能配置可控、缓存加速(利器) 、服务隔离(第三方)、场景异常兜底方案、服务监控与及时响应等等

  • 集群稳定性

主要包括:合理的系统架构、优秀的集群部署、科学的熔断限流、压测机制、精细的监控体系等等

四、系统稳定性建设如何入手?

4.1 系统稳定性建设前提

在提出系统稳定性建设解决方案之前,我们需要明确一下前提条件:

  • 业务熟悉 需要对业务全貌流程熟悉,具备较强的掌控力;

  • 架构明确 需要对系统技术架构熟知并具有一定的实操经验。

只有这样,对业务、架构都具备掌控能力之后,才谈得上去做稳定性建设的拆解和优化,才有基本的保障。

4.2 流程划分

一般情况下,我们提到系统稳定性建设,更像将系统稳定性作为一个专项Topic来搞,从其运行流程来看,主要存在以下几个方面:

  • 前提 目标明确(基准

  • 事前 请求链路优化、服务性能优化&压测、应急预案制定、故障演练

  • 事中 故障监控、定位问题、故障止损、问题修复

  • 事后 故障复盘、整改优化、经验总结沉淀

服务稳定性建设其实是一个系统性的大工程,包括了方方面面。


五、系统稳定性建设的关键动作

从上一Part工作拆解来看,稳定性建设囊括的点比较多,而且杂。更多情况下,我们会做服务稳定性专项,针对某些特定场景下的特定问题而梳理出对应的方案。

那我们可以以小见大,从单服务系统本身出发,提炼看看存在哪些稳定性建设的关键点。其实只有每个单服务环节都稳定可靠,那集群系统乃至整个工程系统的稳定性才有保障。

假如系统面对突增的请求流量情况下,如何做好服务稳定性建设呢?

稳定性建设关键动作拆分如下几类:

5.1 削峰限流

例如,经典的秒杀场景,春节的火车票抢购、电商平台的双11秒杀等等,都是短时间上亿的用户涌入,瞬间流量巨大(高并发)。

不管前期对服务器资源做了如何的扩容,都会存在一个处理上限,所以一定要进行必要的削峰限流策略,类似于城市早晚高峰错峰限行的解决方案。同样,秒杀场景也需要类似的解决方案。

那具体如何来实现呢?

  • 利用消息队列来削峰

消息队列来缓冲瞬时流量,把同步的直接调用转换成异步的间接推送,中间通过一个队列在一端承接瞬时的流量洪峰,在另一端平滑地将消息推送出去。

消息队列就像“水库”一样,拦蓄上游的洪水,削减进入下游河道的洪峰流量,从而达到减免洪水灾害的目的。

  • 利用挡板过滤无效请求

流量挡板过滤,主要是建立一种验证机制过滤掉无效请求,保障核心服务避免受更多外界无效请求的影响。比较常用的方案就是“布隆过滤器”。

  • 产品策略的调整  

产品策略调整是一种特别有效的手段,效果甚至会优于技术层面的改进优化。

例如:利用排队策略,有效打散高并发请求;调整活动宣传时间分散点,避免同一时刻出现高并发请求…

5.2 缓存加速

缓存是解决并发的利器,可以有效的提高系统的吞吐量。按照业务以及技术的纬度必要时可以增加多级缓存来保证其命中率。

主要应用思路:在数据库与服务端之间利用 Redis 做缓存服务,减少请求直接冲击到数据库。

5.3 异步化处理

与异步对应的就是同步,即所有事情排队一件件的有序进行,等上件事情完成后才会去做下一件事情。有点像一根签子串起来的糖葫芦。需要实时处理并响应,一旦超过时间会结束会话,在该过程中调用方一直在等待响应方处理完成并返回。

异步处理不用阻塞当前线程来等待处理完成,而是允许后续操作,直至其它线程将处理完成,并回调通知此线程。

需要强调一点:异步是一种设计理念,异步操作不等于多线程,常见的消息中间件、发布订阅的广播模式等,都可以实现异步处理的方式。

六、稳定性建设过程中的一些经验

6.1 做好压测

提前做好系统压测,做到心中有数,防患于未然,压力预估要切合实际,不要盲目过大。对于性能瓶颈点,尽量提前做好改进优化或者重点关注布防

6.2 应急预案必备

应急预案一定要有,研发人员往往比较自信,这是好事也是坏事,我们需要做最坏的打算。因为经验再丰富的工程师,也无法穷举未来可能发生的意外事件,而故障往往出现在预案之外的地方(墨菲定律)。

6.3 完善监控体系

建立完善的监控、告警机制,尽量让我们第一时间发现问题点,保障报错及时感知。在监控点的设置上,主要原则是:所有的依赖都是不可信的!

6.4 快速响应能力

类似于在行驶的飞机上换引擎,过程中无论发生什么样的故障,立即要动用一切力量“快速”止损。服务要有等级划分,保障抓大放小,保护核心服务原则,如确实存在不能快速定位问题时,可逐层降级。主要目标:防止问题扩大,故障止损,快速恢复。

总结

稳定性建设关键点

  • 削峰限流 面对资源上限,做技术、业务层面的处理,达到流量削峰保障服务稳定性;

  • 缓存加速 利用缓存解决并发,有效提升系统的吞吐量,同时需注意避免热Key、大Key问题;

  • 异步化处理(同步->异步),有效提升响应效率,保障数据的最终一致性。

技术服务于业务

技术还是要解决实际问题来落地。应用场景很关键,所有的优化工作不要单纯为了技术而技术,技术归根结底还是为应用场景和产业落地服务。

可以尝试将业务视角目标做为最终目标,通过一切技术手段来保障目标的达成,从而实现技术价值最大化。

不拘泥于形式,灵活运用

稳定性方案需要视场景而灵活调整应用,切忌生搬硬套。在具体实现过程中,关键要把控主要行动路径,多条路径情况下选取投入产出比最高的那一条。推进一个行动路径:问题驱动(问题感知->问题分析->问题控制->问题解决)。





大家好,我是「架构精进之路」公号作者 flyer0126,公号文章主要来自于个人日常工作问题总结思考,相信问题及解决方案均具有普适性,希望同大家一起学习成长。

大家如有任何疑问/困惑,可关注公号回复关键字 “wx” 添加个人微信,继续勾搭~



往期热文推荐:







「技术架构精进」专注架构研究,技术分享


Thanks for reading!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存